Skip to content

Conversation

@valentinewallace
Copy link
Contributor

@valentinewallace valentinewallace commented Jan 13, 2026

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jan 13, 2026

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@valentinewallace
Copy link
Contributor Author

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

@valentinewallace
Copy link
Contributor Author

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

@valentinewallace
Copy link
Contributor Author

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

@TheBlueMatt
Copy link
Collaborator

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

@TheBlueMatt
Copy link
Collaborator

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

@codecov
Copy link

codecov bot commented Jan 13, 2026

Codecov Report

❌ Patch coverage is 81.62912% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.01%. Comparing base (9df0280) to head (4c0875a).
⚠️ Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/ln/msgs.rs 35.05% 126 Missing ⚠️
lightning/src/util/persist.rs 45.94% 20 Missing ⚠️
lightning/src/ln/channel.rs 93.91% 14 Missing ⚠️
lightning/src/ln/peer_handler.rs 70.58% 9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs 68.18% 7 Missing ⚠️
lightning/src/chain/channelmonitor.rs 91.02% 7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs 0.00% 6 Missing ⚠️
lightning/src/chain/chainmonitor.rs 77.77% 4 Missing ⚠️
lightning/src/onion_message/messenger.rs 92.00% 4 Missing ⚠️
lightning-net-tokio/src/lib.rs 0.00% 3 Missing ⚠️
... and 6 more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4311      +/-   ##
==========================================
- Coverage   86.11%   86.01%   -0.10%     
==========================================
  Files         156      156              
  Lines      102674   102479     -195     
  Branches   102674   102479     -195     
==========================================
- Hits        88415    88151     -264     
- Misses      11764    11833      +69     
  Partials     2495     2495              
Flag Coverage Δ
tests 86.01% <81.62%> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

@joostjager
Copy link
Contributor

Is the Logger a candidate too for this?

@valentinewallace
Copy link
Contributor Author

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@valentinewallace valentinewallace removed the request for review from TheBlueMatt January 15, 2026 19:26
fn message_received(&self);
}

impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?

There aren't that many no-std projects.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

@valentinewallace valentinewallace changed the title Drop Deref indirection for ChannelManager, etc Drop Deref indirection for most trait parameters Jan 20, 2026
@valentinewallace
Copy link
Contributor Author

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

@valentinewallace valentinewallace marked this pull request as ready for review January 20, 2026 18:48
@TheBlueMatt
Copy link
Collaborator

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

@valentinewallace
Copy link
Contributor Author

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

@TheBlueMatt
Copy link
Collaborator

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, LGTM. Will let @tnull comment on whether there's any perceived issues for downstream users.

@TheBlueMatt
Copy link
Collaborator

FWIW, I'd marginally prefer this wait until after #4342 because I want to backport the changes there to 0.2 and it has a bunch of the Deref stuff that would mean rewriting it in the backport which I always hate doing.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I have no real opinion either way whether this refactor is worth the churn, but should work. Also confirmed that LDK Node tests and builds. So fine by me^^

Useful for upcoming commits where we otherwise break SemVer checks by changing
the ALiquidityManager associated types.
@valentinewallace valentinewallace added the weekly goal Someone wants to land this this week label Jan 29, 2026
@valentinewallace valentinewallace removed the request for review from tnull January 29, 2026 22:05
valentinewallace and others added 15 commits January 29, 2026 17:14
Reduces generics and verbosity across the codebase, should
provide equivalent behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Unfortunately the same improvement can't be made for KVStoreSync and Persist,
due to the blanket implementation where all KVStoreSync traits implement
Persist resulting in conflicting implementations.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

This could be split into multiple commits (e.g. one for OnionMessenger message
handler types, one for PeerManager message handler types) but it would require
adding a new IgnoringOnionMessageHandler type for the messenger handlers, due
to the IgnoringMessageHandler's Deref implementation conflicting otherwise.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

weekly goal Someone wants to land this this week

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

7 participants